GDP: Fix bug transforming Blocks in gdp.mbigm transformation#3811
GDP: Fix bug transforming Blocks in gdp.mbigm transformation#3811emma58 merged 11 commits intoPyomo:mainfrom
gdp.mbigm transformation#3811Conversation
… names can be resolved when instance searches for components during M calculations
…into mbigm-resolve-names
gdp.mbigm transformation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3811 +/- ##
==========================================
- Coverage 89.45% 89.44% -0.01%
==========================================
Files 905 905
Lines 105467 105467
==========================================
- Hits 94341 94338 -3
- Misses 11126 11129 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…ransformed correctly.
| m.b.dis1.linear = Constraint(expr=m.b.x * 0.5 + 3 == m.b.y) | ||
| m.b.dis2.linear = Constraint(expr=m.b.x * 0.2 + 1 == m.b.y) | ||
| m.b.d = Disjunction(expr=[m.b.dis1, m.b.dis2]) |
There was a problem hiding this comment.
Quick question: this tests the case where all the variables are defined by the subtree being transformed. What happens if one of the Vars is defined outside the subtree (e.g., on m instead of under m.b)?
There was a problem hiding this comment.
@jsiirola In this example, if we defined variable x as m.x instead of m.b.x, the transformed expression would be:
0.5 * m.x + 3 - m.b.y <= 3.5 * m.b.dis2.binary_indicator_var instead of
0.5 * m.b.x + 3 - m.b.y <= 3.5 * m.b.dis2.binary_indicator_var
Do you see any potential issues with this?
There was a problem hiding this comment.
Nope - that should be fine. I don't think it will be a huge issue, as the change this PR is making doesn't actually affect Vars (I wasn't thinking clearly last night -- you are only getting relative names for active components [Constraints & Disjuncts] - and not Vars).
BUT, this does raise the question: what do we expect the following to do??
m.d1 = Disjunct()
m.b = Block()
m.b.d2 = Disjunct()
m.b.disj = Disjunction(expr=[m.d1, m.b.d2])
TransformationFactory('gdp.mbigm').apply_to(m.b, threads=2)Thoughts? @emma58?
There was a problem hiding this comment.
(Spot checking... this update to mbigm leads to an exception. bigm will transform the model (including deactivating m.d1)
There was a problem hiding this comment.
(@emma58 crawls under a table...)
(From under the table,) we expect the model above to put the transformed constraints on m.b, and to deactivate m.d1 and m.b.d2. Scoping should be determined by the Disjunction and not care about where the Disjuncts are living at all. So basically, the bigm behavior is the desired behavior. I can look at this...
There was a problem hiding this comment.
So actually, the model above transforms without error on this branch (both with m and m.b as the Block being transformed). Even this transforms correctly, as a fun fact:
from pyomo.environ import *
from pyomo.gdp import *
m = ConcreteModel()
m.x = Var(bounds=(0, 10))
m.d1 = Disjunct()
m.b = Block()
m.b.y = Var(bounds=(3, 15))
m.b2 = Block()
m.b2.d2 = Disjunct()
m.b2.d2.c1 = Constraint(expr=m.x <= 7)
m.b2.d2.c2 = Constraint(expr=m.b.y <= 7)
m.b.disj = Disjunction(expr=[m.d1, m.b2.d2])
TransformationFactory('gdp.mbigm').apply_to(m.b, threads=2)
We're somehow getting away with the relative names, though I admit I'm not fully following how at the moment.
jsiirola
left a comment
There was a problem hiding this comment.
I think we've convinced ourselves that this is OK.
Fixes # .
The multiple big-M transformation fails to transform blocks.
Summary/Motivation:
In many cases, we may want to apply the multiple big-M transformation on blocks rather than an entire model.
For example, prior to this PR the following model would result in a failed transformation:
Changes proposed in this PR:
relative_to=instanceonconstraint.getname()andother_disjunct.getname()when setting up jobs for calculating M parameters.Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: